Hi @kyleyannelli
Could you try this branch in your M2 Mac?

@narugit I like the -i option. -i25 -n1000 works great on my machine most of the time. However, this morning I quickly tried the branch when there was nothing but my terminal open. I found that less load on the CPU make a quicker interval work better. I was getting consistent results with -i20 rather than -i25. After launching Firefox & playing a video in the background, -i25 was now more consistent. I didn't have time to test whether or not it was a coincidence. Regardless, maybe the interval lower limit should be lowered to 10 or 15 ms? I imagine this will vary from machine to machine and environment to environment. Either way we are trying to tame a seemingly unpredictable sensor. Perhaps it's fine as it is for now...

Edit: If you'd like I will have more time over the weekend to make a test that can just try every combination of interval by steps of 10 and every retry by steps of 100 to see which combo yields the best results. I'm quite confident with my current values, but I can't help but be a bit curious about the possibility of a better combo.

@kyleyannelli
Thanks for trying out different settings.
It seems like CPU load does have an impact. As you mentioned, it might be a good idea to lower the interval limit to around 10ms.

As a separate idea from the interval option, how about adding an option (-f, --fail-soft) that saves the most recent valid sensor value in /tmp/?
If the smctemp command fails to get a valid sensor reading at some point, it can refer to the last valid sensor value stored in /tmp/.

That sounds good to me!

I'm currently running smctemp in a loop through a system service. Saving the last non zero value in a text file so I can just run cat /tmp/smctemp.val.txt to display in my tmux bar.